Issue being fixed or feature implemented

Fixes #5438.

Protocol version 15 only. This fix was also proposed for 5.0.0-rc.4 as an in-place change at protocol version 14 (#5459, now closed). It is not going into 5.0: testnet already activated protocol version 14 on rc.3, and v1 rejects some ChainLocks that v0 accepts (see "What was done?"), so a block committed by rc.3 voting power during an rc.4 rollout could become unreplayable. Protocol version 14 keeps verify_chain_lock_locally v0, unchanged and identical to v5.0-dev, and v1 is selected from protocol version 15.

Drive rejects valid ChainLocks in block proposals ("received a chain lock ... that we figured out was invalid based on platform state"), failing rounds until Core produces another ChainLock.

A ChainLock for core height H is signed by a quorum Core picks from the quorums active at H - 8. Drive checks it against the two chain lock quorum sets it stores: the set active at its last committed core height C, and the set before it. verify_chain_lock_locally v0 treats a failed check as a definitive rejection in two cases where Drive does not actually hold the signing quorums:

• A quorum mined after C in the same DKG interval. v0 only hands a ChainLock to Core when H - 8 is past the end of C's DKG interval, assuming the quorums cannot change before then. Quorums are mined in the middle of the interval (llmq_test and llmq_50_60 at offsets 10–18 of 24, llmq_400_60 at 20–28 of 288). Once Platform's core height lags Core by more than 8 blocks, a ChainLock signed by the new quorum is rejected locally without asking Core.
• A signing height between the two stored sets after a core height jump across two mining windows. The quorums active there are neither stored set. When both sets fail, v0 rejects.

Seen in the 4.1.1 → 5.0.0-rc.2 local upgrade rehearsal (7 evonodes, llmq_test). Right after protocol v14 activated, Platform block 1122 took 4 rounds (3 min 13 s):

• Platform's last committed core height was 1782.
• Rounds 1 and 2 proposed ChainLocks 1795 and 1800, signing heights 1787 and 1792. Both are inside the interval 1776–1799, after its mining window opened at 1786. The other validators rejected both locally.
• Round 4's ChainLock 1820 was past the interval, went to Core and passed. Rounds 0 and 3 were turns of a stopped 4.1.1 validator.

Each such ChainLock is wrongly rejected with probability 2 / (active quorums + 1): 2/3 on local networks, 2/5 on mainnet and devnets, 2/25 on testnet. The rejection is a deterministic function of the platform state, so all validators agree. It costs liveness, not safety, and every proposer re-proposes Core's best ChainLock until Core has a new one. The logic is unchanged since at least v4.1.1.

Because Drive submits every ChainLock it does not reject to Core anyway (make_sure_core_is_synced), the local check only ever matters as a rejection. The fix is therefore to reject locally only when Drive provably holds the quorums active at the signing height, and to leave the rest to Core.

What was done?

• verify_chain_lock_locally v1, a copy of v0 with three decision changes:

  1. After a failed check against the current quorums, return None (Core decides) when a quorum commitment of the chain lock type can have been mined between C and the signing height. Core only mines commitments inside each DKG interval's mining window. The first such height comes from core_chain_lock.dkg_mining_schedules in the version tables, which holds Dash Core's llmq/params.h values for the non-rotating types, keyed by Core's LLMQ type number. Rotating and unknown types fall back to "any height after C".

     The schedules are frozen in the protocol 15 tables rather than read from rust-dashcore's LLMQType::params(), for two reasons. rust-dashcore's table disagrees with Core for llmq_test_platform and llmq_devnet_platform (interval 288 instead of 24) and for llmq_devnet_dip0024 (mining offsets). llmq_devnet_platform is Drive's default devnet chain lock type. Freezing them in the tables also means a dependency bump cannot change protocol 15's behaviour, and a later protocol can change a schedule with a table edit instead of a new generation. v1 reads them through platform_version; a table without them (None), or a schedule with an interval of 0, is a CorruptedCodeExecution error rather than a panic.

  2. When both stored sets fail, return None instead of rejecting.

  3. Drop v0's round >= 10 branch, which only logged.

  v1 differs from v0 only by turning some Some(false) into None. Every Some(true) and None is unchanged, and every remaining local rejection is on a quorum set Drive holds exactly. When C is already past its interval's mining window (most positions on mainnet), v1 keeps v0's local rejection up to the interval end. v1 never calls Core.

• verify_chain_lock_through_core v1 has Core's verifychainlock check the signature of every ChainLock Drive leaves to Core, before submitchainlock sees it. Dash Core's submitchainlock returns its best ChainLock height without checking the signature when that height is at or above the submitted one (v23.1.8 rpc/quorums.cpp), and Drive reads that answer as "Core is synced", so a forged ChainLock at an already chain-locked height passed.

  • false: Core's verdict, found_valid_by_core: Some(false), so the proposal is rejected as "invalid based on a core request" (not as invalid based on platform state), and submitchainlock is not called. A warning names Core's verdict.
  • true: submitted through make_sure_core_is_synced_to_chain_lock, which decides whether Core is synced exactly as v0's submit branch does.
  • Without submitting (no production caller; the block proposal always submits), verifychainlock is the whole answer and is asked once.
  • RPC error: the proposal is rejected (InvalidChainLock), as a submitchainlock error already is on that path.
  • A genuine ChainLock is rejected in no new case: above Core's best ChainLock both RPCs run the same chainlock::VerifyChainLock, and at or below it Core's tip is at least H - 8 (Core keeps only a best ChainLock it verified), so the signing quorum is selectable. Forged ChainLocks are now rejected by every honest validator instead of depending on each one's Core.
  • verify_chain_lock_locally 1 leaves to Core ChainLocks that 0 rejected, so it is only safe together with verify_chain_lock_through_core 1. A test over every protocol version guards that pairing.
  • This is why these generations cannot replace v0 at protocol version 14: a forged ChainLock that v0 left to Core and Core accepted through that early return is rejected now, so a protocol 14 block committed with one would not replay.

• Version selection. DRIVE_ABCI_METHOD_VERSIONS_V11 is DRIVE_ABCI_METHOD_VERSIONS_V10 with verify_chain_lock_locally: 1, verify_chain_lock_through_core: 1 and dkg_mining_schedules: Some(..) in core_chain_lock, written in struct update form, and only PLATFORM_V15 uses it; v15.rs lists the change. PLATFORM_V14 and v14.rs are unchanged, and DRIVE_ABCI_METHOD_VERSIONS_V10 and earlier only gain the unread dkg_mining_schedules: None (see below), so protocol version 14 and earlier keep verify_chain_lock_locally 0 and verify_chain_lock_through_core 0.

  Other open v5.1 PRs also add a DRIVE_ABCI_METHOD_VERSIONS_V11 for protocol 15: feat(drive-abci)!: state sync via ABCI snapshots with reduced platform state (protocol v15) #4648 (state sync) and feat(drive)!: preserve composite document history across protocol activation #4652 (document history). Whichever lands second rebases and adds its slot to the existing V11 instead of creating another table.

• test::helpers::chain_lock_quorums: test quorums with known keys and ChainLocks signed the way Core signs them.

• The strategy tests' mock Core now also answers verifychainlock (accepting every ChainLock, as its submitchainlock already does).

In-place changes to shipped generations

• DRIVE_ABCI_METHOD_VERSIONS_V1 to V10 (protocol versions 1 to 14) and the mock table mocks/v3_test.rs gain the new struct field core_chain_lock.dkg_mining_schedules: None. Consensus cannot change there: those tables select verify_chain_lock_locally 0, which never reads the field, and no other code reads it. No shipped implementation module is edited (verify_chain_lock_locally v0, verify_chain_lock_through_core v0, verify_chain_lock v0 and make_sure_core_is_synced_to_chain_lock v0 are byte-identical outside their test modules; only the test modules of verify_chain_lock v0 and verify_chain_lock_locally v0 changed).

How Has This Been Tested?

• cargo test -p drive-abci --lib: 4321 passed, 0 failed, 17 ignored (existing #[ignore]s); the chain lock tests (cargo test -p drive-abci --lib chain_lock): 54 passed.
• cargo test -p platform-version: 27 passed, 0 failed.
• RUST_MIN_STACK=4194304 cargo test -p drive-abci --test strategy_tests: 115 passed, 0 failed, 4 ignored.
• cargo clippy -p drive-abci -p platform-version --all-features --all-targets -- -D warnings, cargo check --workspace --all-targets and rustfmt: clean.

Version gate, through the dispatcher:

• A valid ChainLock signed by a quorum mined after C (case A) is rejected at protocols 13 and 14 and left to Core at 15 and the latest.
• verify_chain_lock_through_core: a forged ChainLock is submitted without a verifychainlock call at protocols 13 and 14 (times(0)), and at 15 and the latest is not submitted after verifychainlock fails.
• A forged ChainLock at 1122 (rejected locally by v0, left to Core by v1), with Core's best ChainLock at 1140, is not accepted through verify_chain_lock at any protocol version in PLATFORM_VERSIONS. Pairing V11's verify_chain_lock_locally 1 with verify_chain_lock_through_core 0 fails it ("protocol version 15 accepted a forged chain lock").
• Through verify_chain_lock, protocol 14 still accepts that forged ChainLock through submitchainlock's early return (Core's best ChainLock at 1140), without calling verifychainlock, which replaying protocol 14 blocks needs. The same ChainLock is rejected under the latest protocol version.
• The differential test below also runs the dispatcher at protocol 14 on every history and ChainLock and asserts it returns v0's verdict without asking Core, and runs verify_chain_lock at protocol 14 on both routes: no verifychainlock when submitting, and submitchainlock for every ChainLock v0 does not reject, as the committed protocol 14 blocks were verified.
• Mutation checks: selecting verify_chain_lock_locally 1 at protocol 14 (V10's slot set to 1) fails 3 tests; keeping 0 at protocol 15 (V11's slot set to 0) fails 7 tests; V11 with verify_chain_lock_through_core 0 fails 7 tests (✖); all pass with the tables as committed (✔).

v1:

• Case A and case B. Valid ChainLocks signed by quorums Drive does not hold are left to Core. Before the fix both returned Some(false) under the latest protocol version (✖ before, ✔ after).
• Boundaries. A wrong signer is rejected locally up to the block before the next mining window, and left to Core from it. Past the mining window it is rejected up to the interval end.
• The previous quorum set rejects only where it is known. No previous set means Core decides. A valid ChainLock on an exact set returns Some(true) and a wrong signer Some(false).
• Differential test over simulated quorum histories (steps, jumps, past and inside the mining window, two changes, no previous set). It runs v0 and v1 on valid and forged ChainLocks and asserts:
  • v1 returns v0's Some(true) and None unchanged, and neither asks Core;
  • v1 never rejects a valid ChainLock locally;
  • each history is flagged with whether v0 wrongly rejects a valid ChainLock there, so none can silently stop exercising case A, case B or the mining window;
  • v1's remaining local rejections are reached;
  • through verify_chain_lock on both routes, against a Core that fails every signature and already has a ChainLock above all of them: verifychainlock is asked exactly about the ChainLocks v1 leaves to Core (one call each), which are rejected as Core's verdict; submitchainlock is called only for ChainLocks v1 verified.
• verify_chain_lock under the latest protocol version:
  • case A is accepted through Core: verifychainlock asked once for that ChainLock, then submitchainlock;
  • a forged ChainLock on an exact set is rejected without calling Core (times(0) for both RPCs);
  • a forged ChainLock left to Core, at 1122 (newly deferred by v1) and at 1136 (past the DKG interval, deferred by v0 too), with Core's best ChainLock at 1140: rejected as Core's verdict (found_valid_by_core: Some(false), found_valid_locally: None), and submitchainlock is never called (times(0)) (✖ before the verifychainlock step: accepted through the early return; ✖ when the check sat in verify_chain_lock_locally: reported as found invalid locally; ✔ after);
  • without submitting, verifychainlock is asked once about a ChainLock left to Core, and its verdict is the result (✖ when the check sat in verify_chain_lock_locally: asked twice; ✔ after);
  • a ChainLock left to Core that verifychainlock accepts while Core's best ChainLock is 10 blocks behind it is not accepted (core_is_synced: Some(false));
  • a verifychainlock RPC error reaches the proposal as Err(CoreRpc), without submitchainlock.
• DKG schedule:
  • first_possible_quorum_change_after is checked at the window boundaries of all eleven non-rotating types, including llmq_devnet_platform, against the latest protocol version's table. The expected values are keyed by dashcore's QuorumType and the table by Core's LLMQ type number, so this also checks the numbering. Rotating types (including llmq_devnet_dip0024) and unknown types fall back.
  • v1 reads the schedules from platform_version: with an empty table, a wrong signer the latest table rejects locally is left to Core; None and a zero interval are CorruptedCodeExecution errors. Every platform version's schedules are unique per quorum type with the mining window inside the interval.
  • A wrong signer under llmq_400_60 is rejected before mainnet's mining window and after it, and left to Core inside it.
• Mainnet ChainLocks 2555653 and 2555665 against the four llmq_400_60 quorums active at their signing heights, with quorum hashes in the byte order Drive stores them. Both verify, and a different block hash is rejected. For 2555665, choosing by the hashes as displayed would pick a different quorum. This pins Drive's quorum choice, digest and byte order to real Core data.
• Mutation checks on v1 (run on an earlier revision of this branch; the window logic they mutate is unchanged since): treating "inside the mining window" as "past it" fails 3 tests; an off-by-one at the window end fails 3 tests; restoring the rejection when both stored sets fail fails 2 tests.

Breaking Changes

Consensus change at protocol version 15. A protocol 15 block proposal whose ChainLock was signed by quorums Drive does not hold is checked by Core's verifychainlock instead of being rejected, and a forged ChainLock Drive leaves to Core is rejected even when Core already has a ChainLock at or above its height. Protocol version 14 and earlier behave as before.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed
• If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · 2cd9d44

• Bots — coderabbitai skipped after the window · thepastaclaw ✓
• Self-review — post /self-reviewed
• Build green
• Approvals — you own every area touched; none needed

When every merge requirement is met, the PR Hygiene check passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.